1. Field of the Invention
The present invention relates generally to networked systems, and more particularly, to the processing by a server of requests from a plurality of communicatively coupled computing machines in a network environment.
2. Discussion of the Related Art
Generally speaking, computer networks include a plurality of communicatively interconnected computing machines (e.g., terminals, micro-computers, mainframe, etc.). Networks seek to better utilize computer resources (e.g., memory, hard disks, printers, processors, files, programs, and processing capabilities) by enabling the constituent computing machines to share the computer resources.
Sharing computer resources in a network enables a requesting computing machine, also referred to as a client, to submit a request for an operation to be performed on another networked computer, referred to as a server. Servers include, for example, database servers, file servers, and print servers, and respond to requests by clients for the associated resources provided by the servers. The server processes the request and provides an appropriate response informing the requesting client of the results. Instances in which such an arrangement is particularly beneficial exist where a large database is utilized by a number of users or where a set of users require access to a same set of information within a dynamic database. In such cases, well known benefits are realized by the sharing, via a database server, of access by users to the information and the operations performed by the database server upon the information such as, for example, performing searches of the database in response to requests submitted by the networked users.
In a typical client/server based network, a number of diverse clients are communicatively coupled to one or more servers in order to facilitate the submission of a variety of requests to the servers. A particular type of network server is a database server. Database servers maintain and manage a shared database in a network. By sharing the database, it is possible for the database server to maintain a single master copy of the database. Networked client computers send requests to the database server to add additional records to the database, remove records from the database, and update records in the database. In addition, the clients submit database queries to the database server concerning the information records stored in the database controlled by the database server.
Even with a database server dedicated essentially to responding to database requests, when a number of users submit queries to the server in a very short time period or the database server is processing a very large, non-interruptable task, a system bottleneck arises. Consider, for example, a business accounting system having a centralized database maintained and managed by a database server communicatively coupled to a number of client machines set up for use by accounting personnel. Assume that the accounting database includes various income and expense accounts. Associated with each account are a number of transaction dates, amounts, comments, etc. A number of accounting personnel may submit substantially simultaneous query requests to the database server. The database server, in response to the simultaneous requests, allocates its processing resources to process the query requests as quickly as possible, while avoiding errors resulting from a query to a partially updated database.
In general, there are various response time requirements for execution of database queries by a server. A client machine may submit a high priority query needing immediate attention. On the other hand, another client machine may submit a low priority request that may be responded to by the database server at a later time when higher priority queries are not pending.
Continuing with the foregoing example of a database server maintaining account information, a user may submit a high priority request via a network client requiring immediate attention by the server such as, for example, a particular account balance query requiring an expedited response from the server. The client maintains a connection to the server until the client receives a response to the request from the server. In other instances, a user may not need an immediate response. For example, a user logged onto a network client may need a set of the previous day's balances for a designated set of accounts at the beginning of the following business day. Such a request would typically be considered a low-priority request.
In order to avoid tying up network resources such as database servers during high usage periods, known systems include means for delaying carrying out low priority requests from clients. In such systems, the user submits a low priority request, for example, during the previous business day. The request is processed in due course by the database server during a low-usage time (e.g., after business hours). The requesting client, rather than maintaining a connection to the server in order to receive an immediate response, typically terminates a network connection after transmitting the request. The requesting client receives the results at a later time after re-establishing a connection to a network entity containing the results of the request, or by receiving the results in printed form.
In a known system, a client submits a request to a connected server and then disconnects before receiving a response from the server. After processing the request, the server transmits the results to an electronic mail (email) location designated in the request. Thereafter, the client retrieves the results of the requests from the electronic mail location.
While submitting requests that direct the output to be mailed back to the client does, in effect, enable a client to "disconnect" between submitting a query and retrieving the results, it is inefficient from a design perspective, since it requires supporting, by the client machines, two separate and architecturally distinct interfaces to accomplish a single task. A client machine, in order to utilize such a system must support an on-line connection to the server for submitting a request and a separate email interface for reading the results. Furthermore, the presence of two different interfaces may require a user to learn how to use two separate software tools (e.g., an on-line server query tool to submit a request to the server, and another tool to interface with the emailed results). Alternatively, additional integration software (e.g., a user shell) can be designed to accommodate both interfaces in a manner that is transparent to the user. However, there are clearly implementation costs and complexities that arise from the existence of this hybrid client/server interface.
Yet another approach to enabling a user to initiate a request to a server and disconnect before receiving the results involves the use of "detached processes." Detached processes are essentially programs that receive requests from users on client machines that are eventually to be submitted to a server. The detached processes may, in turn, impersonate the users while submitting the received requests to the server and obtaining the results. The user, at some later time, obtains the results of the request through yet another procedure such as establishing a connection with the detached process in order to obtain the results of the request. It is noted that, the detached processes are constrained by the same request/response protocols of the clients. For example, the detached processes will likely maintain a continuous connection to the server while the server processes the request.
The detached process approach, while providing a number of well known advantages over direct on-line connections to servers, has certain drawbacks. Since the detached process runs separately from the database server (either on the same machine or on a separate machine), there are processing, memory, and possibly network costs associated with sending the requests and results between the detached process and the database server. In addition, the detached process adds a separate element to the total system that must be monitored so that the detached process is always running and available to handle requests. Furthermore, the use of a detached process introduces yet another communication link in a network that must, in a secure network, be guarded. Thus, detached processes add complexity and administrative costs to the total system which, in some cases, are too prohibitive to justify implementation or use.